A certificate system provides a security framework to ensure that network resources are accessed by authorized users. The certificate system is capable of generating digital certificates (certificates) for different users to verify the identity of a presenter. The certificate system can include interoperating subsystems to perform various Public Key Infrastructure (PKI) operations, such as issuing, renewing, suspending, revoking, archiving and recovering keys, publishing Certificate Revocation Lists (CRLs), verifying certificate status, and managing the certificates that are needed to handle strong authentication and secure communications. The certificate system can include a Certificate Authority (CA) subsystem to issue and revoke certificates, a Key Recovery Authority (KRA) subsystem, also known as a Data Recovery Manager (DRM) subsystem, to recover lost keys, an Online Certificate Status Responder (OCSP) subsystem to verify whether a certificate is valid, a Registration Authority (RA) subsystem to accept certificate requests and verify whether a request should be approved, a Token Key Service (TKS) subsystem to format tokens (e.g., USB storage device, key fob) and process certificates on a token, and a Token Processing System (TPS) to manage certificates on tokens.
Each certificate subsystem belongs to a security domain. There can be multiple security domains in a certificate system. A security domain is a registry of certificate subsystems that provide PKI services. For example, a CA subsystem registers information about itself with a security domain so users of PKI services can find other services by inspecting the registry.
Typically, a security domain has a single domain manager to keep track of which certificate subsystems belong to a security domain. The domain manager can add a certificate subsystem to a security domain and can remove a certificate subsystem from the security domain. When a certificate subsystem is installed, the subsystem undergoes a registration process and contacts the domain manager as part of its registration process to request to join a security domain. The domain manager, however, can be a bottleneck in the registration process if the domain manager is offline. A certificate subsystem can also contact the domain manager and request to be removed from a security domain. The domain manager, however, may not have the bandwidth to handle numerous security domain requests, leaving some requests unprocessed.
The single domain manger is usually the first certificate authority (CA) subsystem (root CA subsystem) that is installed in a certificate system. Usually only a limited number of users (system administrators) have the credentials to access the domain manager. The process to add or remove certificate subsystems or change certificate subsystem security domain data, therefore, is also limited by the number of system administrators that have the credentials to access the domain manager. In addition, typically the single domain manager manages the topology data for a security domain. The topology data can include a list of subsystems in the security domain and the information for each subsystem. The access to the topology data, therefore, is also limited to the system administrators that have the credentials to access the domain manager. As a result, only a limited number of system administrators can view the topology data for a security domain. A root CA subsystem is the single domain manager that can process view, add, remove, and change requests; therefore, the root CA subsystem is under a heavy load of traffic and may not always be available. The current state of the art, therefore, does not provide a way to process security domain requests when a user (system administrator) does not have the credentials to access the security domain manager and when the security domain manager is not available.